Would it be worth to add an assert here?

I think not here - I think returning NULL if it's not initialised is potentially useful API. You might want to perform some operation if it's active, but not start it.

Callers could maybe assert, but I don't think asserting ahead of a NULL dereference is that useful either - it will go bang with a pretty easy to debug backtrace.

What does it do?

Means we can optionally include stuff via a TOOLCHAIN_ARMC5 folder. At the minute we only have the labels TOOLCHAIN_ARM and TOOLCHAIN_ARMC6. Used for the base <array>, <initializer_list> bits for ARM C 5.

(We only need to tiptoe around with namespace mstd and <mstd_xxx> for places where we are up against an existing header file; when we're supplying something ARM C 5 lacks altogether, we can just go straight in with the standard name in namespace std.)

mbed.h is included above, so there's using namespace std and using mstd:atomic that both brings atomic in the global namespace.

This is actually pulling it into this unnamed namespace.

I previously claimed that a global-scope using mstd::atomic would override a more general using namespace std for atomic, and I'm sure I'd tested this, but seemed not to work here.

But putting it into an inner namespace like this does work - it searches innermost namespace first.

I somehow missed the anonymous namespace declaration. Good to know.

Why not have <mstd_initializer_list> for initialiser list ?

Good general question - for consistency, it would indeed make sense to have mstd_xxx for all headers we think are good, to "approve" them, and to allow a single using namespace mstd, even if we currently don't need any adaptation, and it would just copy everything over. If you want to fill them in, I wouldn't object, at least for "not-too-bloaty-for-embedded" stuff.

How do we get constexpr replacement if std::min and std::max are directly imported ?

As mstd::min and mstd::max. For ARM C 5 those are these replacement implementations, rather than being aliased to std::min like for the other toolchains.

I'm not sure to agree with that definition; in C++14 a constexpr object can invoke non const member function in a constexpr context. In C++11; constexpr equals const.

constexpr implies const method in a C++11, yes, but I don't think that's an issue here. That would be used as:

MSTD_CONSTEXPR_FN_14 int my_complicated_method() /* const or not */ {
      // some-multi-line thing
     return whatever;
}

Flipping from constexpr in C++14 to inline in C++11 seems right to me - either member or non-member.

Or were you misunderstanding OBJ - that was intended for a constexpr object:

static MSTD_CONSTEXPR_OBJ_14 int npos = -1;

I was thinking of the following case:

struct Foo { 
    constexpr Foo() { }

    // not a const member function!
    MSTD_CONSTEXPR_FN_14 int get_something() { /* ... */ }
};

static MSTD_CONSTEXPR_OBJ_14 Foo foo;

void foo() { 
   // error call of a non const function on a const object
   auto v = foo.get_something();
}

Seems fine to me? In C++14, the function is constexpr, not const, and it fails to compile.

In C++11, the function is inline, not const, and it fails to compile.

embnedded => embedded

See comment above.

Question, why use FUN as identifier ? __fun or _Fun where not good enough ?

It came from the revised-in-2017 standard text (https://cplusplus.github.io/LWG/issue2993). We're not actually using it anyway, as that version seems to be too advanced for ARM C 5. I'll remove the dead code.

Do you mean not_fn as the function name ?

Spot the person rushing to get this in before holidays. (To ensure we don't have a breaking change versus a shipped mbed_cxxsupport.h)

To some extent this is justified for the bulk of the code being for ARMC5 only, and it's not-officially-supported status, but yes, testing clearly needed.

Glad to see that class getting in.

Yes, but sadly in use, it increases code size, at least in my tests.

You'd think it was "free", but the compiler doesn't seem to be as good at optimising out shuffling. For example, given:

 if (!ptr) {
     ptr = make_unique<Thing>(whatever);
 }

I've seen ARMC5 at least put in a pointless delete-of-current-pointer-contents on the assignment (but we just tested that the pointer is currently empty), and then a pointless delete of the temporary returned by make_unique (we know we just moved out of it).

Avoiding make_unique helped a bit, but still not as good as doing it by hand.

Maybe other compilers (and their std::unique_ptr) do better?

Much as I want to believe the C++ guys' claims that C++ is as efficient as C, I keep seeing cases like this where it's just a bit too hard for the compiler to totally eliminate the generic stuff, and it does get bigger. At this embedded scale of tens of kilobytes of ROM and RAM, the impact is real...

Lots of little micro things you wouldn't think of.

Plus the annoyances like what I hit with SingletonPtr here - took me a number of hours to understand the initialization rules enough to comprehend the "mixed zero and constant initialization" problem I was hitting and deal with it to get them back out of the final link.

Was watching this while debugging that one: https://www.youtube.com/watch?v=D7Sd8A6_fYU

Made me a little grumpy - yes, there are misconceptions about C++ for embedded use, but it does also have real issues. And yes, sure, stronger type checking can move more debugging to compilation time, but often that debugging is much harder...

It would be sweet if our documentations were explaining which C++ features is safe to use and what are the impacts on code size/speed (I'd love to write that). I hope most of the code won't turn into crazy template so debug ability should be okay; too bad that compilers doesn't have attributes to treat constructors as literals. It would be really useful for basic building blocks such as Callback.

Much as I want to believe the C++ guys' claims that C++ is as efficient as C, I keep seeing cases like this where it's just a bit too hard for the compiler to totally eliminate the generic stuff, and it does get bigger. At this embedded scale of tens of kilobytes of ROM and RAM, the impact is real...

I'd be interested to measure the impact on a real world application. Not that I doubt there is one (there will be one as long as there's no destructive moves) but an accurate picture would help us create guidelines to our community of users and internal developers.

any plan to add the timed_ versions ?

We need chrono for ARMC5 first. That feels like a separate project.

If licensing permitted just lifting the ARMC6 implementation...?

This is one case where ARMC5 is a significant blocker. It would be easy to bring chrono in to use for the other 3 toolchains, but any attempt to keep ARMC5 building blocks it. Could make all relevant APIs conditional on ifndef __CC_ARM, but don't fancy that either.